SuperHack

home *** CD-ROM | disk | FTP | other *** search

/ SuperHack / SuperHack CD.bin / CODING / 8_16BIT / PPFAQ.ZIP / PIC84FAQ.TXT next >

Wrap

Text File | 1995-03-16 | 32.0 KB | 658 lines

Frequently Asked Questions About PIC84PGM.ZIP With Some Answers =============================================================== (Original 11th March 95) V-0.1 16th March 95 David Tait Electrical Engineering Dept The University Manchester M13 9PL UK david.tait@man.ac.uk Copyright (C) 1995 David Tait Permission is granted to copy, store or redistribute this document. Introduction ------------ PIC84PGM.ZIP (available from ftp.ee.ualberta.ca/pub/cookbook/comp/ibm, Microchip's BBS in the 3RDPARTY library, and elsewhere) contains a crude ASCII schematic for a simple PIC16C84 programmer designed to be attached to the parallel port of a PC. It also includes the source code for some rudimentary C and QBasic drivers for the hardware. In case you don't know, the PIC16C84 is a single chip microcontroller which fits a lot of good things into a small (18-pin) package; in fact it is a developers dream come true. It's fast, moderately cheap, and best of all it's program is stored in EEPROM. This last feature makes it especially convenient in the development stages of a project; it even has cheaper one-time programmable (OTP) cousins for use in a final product. Another useful attribute of the 16C84 is that it can be programmed with only a few signals (called serial mode programming) and what's more, the required signals have very lax timing specs. As a considerable bonus, the manufacturer, Microchip Technology Inc, provide free PIC development software via their BBS or Internet site. You can also grab useful software and information from the Internet site of Parallax Inc, a company that supports the PIC series. It is true that both these companies also sell some reasonably priced prototype programmers, but if you want a dedicated 16C84 programmer, the DIY route is quite attractive. When I looked about a year ago I couldn't find anything to help me build a programmer so I just got the required info from Microchip and did it myself; it was not very difficult (I had to have a couple of goes at getting the hardware right though). I decided to make my info available on the net just in case it helped anyone about to re-invent this particular "wheel". It turns out I didn't explain things as comprehensively as I should have done and the legacy of this project has been a steady stream of e-mail that has to be answered. It seems that many people from all over the world are just discovering the delights of the 16C84 and would like a cheap and cheerful development system to go with it. Helped no doubt by the very useful PIC FAQ produced by Tom Kellett et al, these same people get to hear about my humble efforts. I guess most people that grab the files just take the good bits (if indeed there are any) and get on with designing their own superior versions. It's likely I'll never hear from this group at all. I suspect this group own oscilloscopes. On the the other hand there are some people that assume that my design can replicated exactly and will work from the first moment they apply power, and though this will be true for a lucky few, on the whole this group run into some kind of hardware/software problems. Needless to say this group are unlikely to own oscilloscopes and I certainly do hear from them. I try hard to help, but faultfinding by e-mail is a frustrating experience at best. I feel responsible for their disappointment and frustration. All is not lost though; there are some common stumbling blocks that account for most of the problems that can crop up. The purpose of these notes is just to describe the potential gremlins and their cures, and to answer one or two other questions that I'm often asked. I'm sorry this file is so long and rambling, but I hope that if I answer everything now as fully as possible, I might get a rest from answering the same questions multiple times by e-mail. Some answers refer to my programs for reading a PIC. The software is supplied as both C (rp.c) and QBasic (rp.bas) source and should be available where you picked up this document or even packaged with it. The software is only designed to read program memory but it's really very easy to modify it to read other areas of the 16C84 memory. See the source comments for details on how to run the programs. Hardware Questions ------------------ Q1. Has _anybody_ got this to work? A1. Yes. At least 40-50 people have been kind enough to send me mail to say they got it working themselves. I've lost count of the number people I have tried to help by e-mail. I suspect that a great many others have got it to work too, but they have not got in touch for one reason or another. Ask any shareware writer about the likely ratio of registered users to total users and then remember my stuff is free, so there is not much incentive to get in touch. (Unless there is a problem that is, which is the motivation behind this document in the first place.) As I write this, I see that the file has been downloaded well over a thousand times from the Microchip BBS alone. Q2. Your drawing shows devices marked 74xx07 and 74xx06. I can't find them in any catalogue, where can I get them? A2. I just meant any TTL open-collector (O/C) buffer like the plain 7407 or 7406, or better still if you can get them, the 74LS07 or the 74LS06. Similar members of the 74HC family are probably OK if such things exist. One of my programmers uses a 74LS05 which is really out of spec in this circuit, but seems to work fine. I didn't think the choice of buffer was critical, but a few reports have made me think again about using the plain 7406 or 7407. I understand that another popular 16C84 programmer design uses a 74C906, and this slightly more modern device may have been a better choice for my programmer too. If you want to try one, please note that it is not a drop-in replacement for a 7406. It seems you can be even more adventurous about replacing the buffer: one person told me that he couldn't find a suitable chip in his junkbox so he replaced the buffers with 5 VMOS FETs and they worked a treat. I suppose it is even possible to connect the PIC directly to the parallel port and do away with the buffers altogether. Though this needs a little trickiness because RB7 is read/write. Anyway, I wouldn't recommend this, but I know it can be done. For the real minimalist, do this and replace the electronic switches with manual ones and get the program to prompt you to operate them at the correct times! Q3. Your diagram implies that either inverting or non-inverting buffers can be used. Surely they can't be interchangeable, or can they? A3. Well not exactly. This is something I should have mentioned in the README but didn't. You _can_ use either type of buffer but you must make sure the software is changed accordingly. As supplied, the source and the EXE file assume inverting buffers are used (i.e. the 74xx06 type). In fact as one of the 6 available buffers is not used I actually missed an opportunity to make the hardware self configuring. If I had connected the input of the spare buffer to an output pin of the parallel port and the output of the buffer to an input pin the software could have worked out itself whether the buffer inverted or not. Oh well. You should refer to the software section if you happened to select non-inverting buffers to build the circuit. Q4. It would make my life easier if you could supply me with a PCB layout. Do you have one? What about a better diagram at least? A4. Recently one satisfied user promised to send me a layout so that I could make it generally available. I don't have it yet, but when I do I'll ask the designer whether I can upload it to the circuit cookbook site. Actually it's not obvious that a PCB layout of the circuit exactly as shown would be the most useful. I mentioned in the README file that the spare sections of the 4066 could be used to isolate the RB6 and RB7 pins from the buffers. Maybe it wasn't obvious, but I meant that this would be a good way to implement an in-system programming system. You'll also need to arrange for MCLR to be taken to +5V for the PIC to run - a diode to +5V is probably OK; in fact someone sent me a diagram of exactly this setup so they obviously got the message. If you want to design your own PCB it shouldn't be too much of a problem; the low complexity of this programmer is ideally suited for use in evaluating the numerous demo versions of PCB software that are in circulation. I was quite impressed with a demo of CIRCAD (no, not the program by the same name that's on the Simtel sites). As I write this, a copy can be snatched from ftp://mobius.gmu.edu/pub/circad. It has both PCB layout functions and schematic capture so you can draw a better diagram yourself! Recently Don Mckenzie has posted info on the 3RDPARTY file area of the Microchip BBS about a supply of PCBs for his own programmer design. He doesn't have Internet access but you can reach him on the Microchip BBS e-mail system where his user ID is simply don mckenzie. I only mention this here because he supplies his own improved version of my QBasic software and he was kind enough to send me a free PCB :-) See the PIC FAQ about connecting to the BBS if you want to get in touch with him. Q5. I have built your hardware exactly as shown and it doesn't work! I have checked it a hundred times and it looks OK to me. Are you _sure_ the diagram is correct? A5. Well, the fact that it doesn't work might not be due to the programmer hardware alone and you should look at the answers to the software questions too. To answer the correctness question: the diagram is correct as far as it goes. My first programmer of this type was more or less exactly as shown. However it does suffer from some sins of omission. I should have made it clear that it is necessary to add decoupling capacitors for the 4066 and the buffer. The decoupling components are not shown in the diagram, but 100nF caps should be connected between, and close to, the power pins of both chips. As one of my e-mail correspondents put it: if the person building this circuit didn't know that they should add decoupling caps, then they are going to have a terrible time getting their PIC applications to work. That made me feel good for a minute or so, then I felt guilty again because I hadn't made the need for decoupling explicit. The circuit is deceptively simple, but it is not that easy for an absolute beginner to go from my diagram to a working programmer. Not really a correction, but a couple of LEDs on VPP and VDD, while not helping the circuit work any better, are at least colourful and let you know that things are working. By the way, rather than just giving the board a visual check, I would urge you to write a simple program to toggle the LPT output pins (D0-D3) and read the input pin (-ACK) - QBasic is great for this. If you don't have any test equipment, use the spare buffer to drive an LED and use this as a simple logic probe. Getting the pins to change as expected will go 99% of the way to solving your problems. Q6. Why 13.8V? A6. Initially I used a power supply intended for citizen's band or amateur radio equipment (I have such a thing handy because I'm a radio ham - G0JVY). As much of this equipment is expected to be used mobile, i.e. in a car or truck, the power supply is designed to produce the typical voltage of a fully charged car battery - 13.8V apparently. You don't have to follow this slavishly; the spec is something like VDD+4V (i.e. 9V) to 14V, but I'm reliably informed that using too low a voltage can lead to unreliable programming. A 3-pin 12V regulator, like a 7812, with a couple of silicon diodes from its ground lead to ground gives a decent enough 13.2V when supplied with 16-18V from a unregulated wall adapter. Following a suggestion made on the net, I mentioned in the README that it's possible to get power from a spare floppy disk lead. After hearing a sad tale from someone who tried this, I no longer think that's a good idea. Q7. Anything I should know about the cable between the PC and the programmer? A7. Keep it short for one thing. There are some fast pulses travelling along this connection and long runs of ribbon or multiway cable terminated in a just a TTL input can mangle them. I suppose twisted pairs with separate earths and good terminations would be best, but my own cable is nothing special and I have no problems. Hopefully you will not either. However, if the programmer seems to fail with a verify error at location 0 (the typical indicator of programmer malfunction), it is worth paying some attention to the waveforms produced at RB6 and RB7 and the inputs of their associated buffers. Ideally you would use an oscilloscope to view them; perhaps then you can see what might be done to improve them. Resistive terminations should be the order of the day, but if you are not proud, don't own an oscilloscope, and are ready to accept a more empirical approach: two small caps (10-50pF) one between RB6 and ground and one between RB7 and ground are certainly worth a try. This has been suggested to me a couple of times. One person mentioned that the circuit worked with an oscilloscope connected to RB6 and RB7 but failed to do so when the scope was not connected, so, being a clever chap he simulated the two scope connections with 1M resistors in parallel with 12pF and this solved his problem. Q8. I have read the programming specs in data sheet DS30189C and your design cannot possibly work. If you had read them too you would have seen that the max current from Vdd (+5V) is rated at 50mA. Now, let me point out that the R-on spec for a 4066 switch is 80 Ohms; perhaps you are not aware of Ohms law, but it says that 0.05*80 = 4V will be dropped across the switch leaving only 1V for the PIC! What's more the maximum possible R-on is much higher than 80 Ohms leaving even less for the PIC. What do you have to say to that? A8. Thanks for the electronics lesson. I can only plead ignorance (though not of Ohms law!) because I designed the circuit based on the information in DS30189A which is an earlier version of the data sheet you quote. There was no mention of such a high current rating in my data sheet. In fact, because my programmer _does_ work, it seems most unlikely that a typical PIC needs anything like this much current. I have measured the voltage drop across the Vdd switch and it is typically only a few tens of mV (though I must admit I've only tried this with a few different PICs and 4066s). I also have connected a scope to Vdd during programming and I couldn't detect any short glitches which might indicate large current demands for short amounts of time. If you are still worried about this, the 4066 switch can be ditched in favour of a separate bipolar transistor switch. Here is an ASCII sketch of a suitable replacement: +5V + ___ | +--[___]---+ | | |\ ___ | B |/ E <D2>----| >o---[___]---+--------| PNP |/ |\ C | +---+ Vdd The resistors can be 10K. You should retain the 10K//100nF network connected to Vdd. Of course it makes sense to change the Vpp switch too so that you don't need the 4066 at all (the Vpp switch should have E connected to +13.8V and C connected to Vpp and be driven by the buffer connected to D3). If you have already built the hardware and used a socket for the 4066, a neat idea is to put the transistor switches on a DIL header and simply replace the 4066 with this. The software will need minor changes to account for the inverted operation of the new switches. In the programs you'll find definitions for controlling the LPT pins for both types of buffer. To get an inverted signal just borrow the definitions for the opposite type. Q9. Your circuit has an error! Have you forgotten to include a pull-up resistor for the O/C buffer driving the ACK pin (pin 10)? A9. I think you are right. However, I didn't forget to include one because I thought that the ACK pin had an internal pull-up. I don't use ACK pull-ups on my own programmers and they seem to work. Anyway, it can do no harm, and probably some good, if you fit a 10K resistor between the ACK pin and +5V. Certainly this is something to try if you are having trouble getting the programmer to work. Q10. Are there any other designs available, especially for other members of the PIC family? If not can your design be suitably modified? Where can I get more PIC info? A10. The 16C84 is particularly well served by DIY programmer designs and there have been more universal designs published in several hobby mags (see the PIC FAQ for some pointers). The 16C5X family cannot be programmed in serial mode, but I believe most, if not all the 16CXX PICs could be programmed using some approximation of my hardware. However, the programming pulses required are considerably different to those produced by my software; they need to be more accurate for one thing. Although it's not an entirely trivial job, it is worth getting the programming specs and having a go at writing your own programmer software. For more info on PICs I only need to give you one suggestion: get the PIC FAQ. The FAQ will tell you about the Microchip BBS and Internet sites, the PICLIST mailing list, the Parallax Internet site and lots more besides. To get the PIC FAQ you can use Andy Errington's Web page: http://www.lancs.ac.uk/people/cpaame/pic/pic.htm It's links are growing daily and one should point at the latest copy of the PIC FAQ. By the way, Andy recommends the everyone interested in PICs should equip themselves with a copy of Microchip's Embedded Controller Handbook. Q11. How many programming cycles can I expect to get? A11. How long is a piece of string? The expected range of possibilities is very large. You should be able to rewrite program memory an absolute minimum of 100 times and typically a few hundred to maybe a thousand times. Data EEPROM can be reprogrammed many hundreds of thousands of times I think. Q12. Can your hardware be used to read a code-protected 16C84? Do you know how to read a code-protected PIC? A12. I have heard speculation and rumour, nothing more. Q13. Can I use your programmer for in-system programming? A13. See A4 above for some hints. Also see Microchip application note AN589 by Robert Spur for another design. Although the application note gives the core routine for serial mode programming, it needs a wrapper to use it as ready-to-go progamming software. It's possible to use pp.c or pp.bas instead with just a few mods. Q14. You say in the comments of pp.c that your design is _not_ a production quality programmer. What is it then? A14. It's a prototype programmer. These are terms used by Microchip. The difference is based on the thoroughness of the verification procedures used. A production programmer not only verifies with Vdd set at a nominal +5V, but it also does so at other values (typically +4.5V and +5.5V). It's no doubt possible to modify my programmer to do this, but if you are going into production and programming many PICs you probably owe it to your customers to invest in a more upmarket programmer. Q15. Thanks for making your programmer design available and I am very happy with it. How can I thank you? A15. Spare a moment to let me know you got it working by sending an e-mail message to david.tait@man.ac.uk (or to user ID david tait on the Microchip BBS). A postcard would be nice if you can't send e-mail. Anyway, if it has saved you a bit of time and effort I'll be happy. Software Questions ------------------ Q1. Do I need a QBasic compiler to run the QBasic program? A1. No. Just use the interpreter that comes with MS-DOS. I wrote the Qbasic stuff so that people without a C compiler could still hack something. I'm afraid I learnt QBasic from the on-line help in a couple of days and it shows. Q2. I built your hardware design using a 7407. I tried the EXE supplied and it didn't work. I tried the Qbasic program and it didn't work either. What is wrong? A2. Try a 7406 instead! The trouble is that both the C and QBasic programs were set up for hardware employing inverting buffers like the 7406. This means the EXE was built for 7406 based hardware too. The C program can be reconfigured for non-inverting buffers like the 7407 by including the line "#define U7407" (it is commented out in the distributed version). The Qbasic program can be set up for a 7407 by using these definitions: CONST DataInv = 0 CONST VppOn = 8, VppOff = 0, VddOn = 4, VddOff = 0 CONST ClkHi = 2, ClkLo = 0, OutHi = 1, OutLo = 0 The comments incorrectly suggest that you should use ClkHi = 4. Surely very few programs have bugs in the comments! Q3. I monitor the VDD and VPP supplies on my board with LEDs and I see that one of the supplies is turned on after I reboot my machine. Is it OK to insert the PIC into the programming socket despite this? A3. No. Just run the software with the port number as the only argument; the program will initialise the port and the supplies will be switched off. Q4. I am using the C software and I know it is correctly configured for my hardware but it still doesn't seem to work. Whenever I try to program a PIC I get an error message something like this: pp: 0000: YYYY != XXXX pp: Verify failed during programming Nothing I do gets round this. Can you help? A4. Reports from people getting this error message account for quite a bit of the e-mail I receive about my programmer. Unfortunately on its own it is not a very helpful diagnostic. The error simply means that the programmer tried to program the very first location in program memory to XXXX (hex) but read back YYYY. To save programming cycles the software doesn't try a second time. (When things are working properly all locations should program first time anyway.) The fact that it was the first location that failed is usually indicative of some sort of programmer malfunction. If verify errors occur at other addresses it's just as likely to be caused by a PIC's EEPROM becoming unreliable. I suggest the real answer to your problem will be found somewhere in the answers to the hardware questions. However when you've tried all the ideas from there, you might start to suspect a timing problem. In this case it's worth trying the QBasic software to check your hardware - the QBasic interpreter runs slowly enough for timing not to be a problem. If the QBasic stuff works then change the delay constants (THLD, TSET and TDLY) in the C source. Compare pp.c with the source of my PIC reader rp.c to see what changes I have made for my own 486DX33. The main idea is to ensure TDLY is about 1 microsecond, and THLD=TSET give the hardware enough time to respond. In fact the constants I use in rp.c give very long delays, but as they are still very small compared to the time taken to program a location (about 10ms) they don't add much to the total time it takes to program the device - there is really no need to spend time optimising the values. If you are using my EXE file with a 486 then that may be the problem in itself. I suspect the version of Borland C I use has a bug in the delay() routine (needed to get the 10ms programming delay) that only manifests itself with some CPU types, though I haven't been able to pin it down. Try recompiling, maybe the bug is fixed in your compiler. If you do recompile you can get stung by another problem: the latest C compilers will optimise the tiny_delay() routine to nothing. This will only be a problem on a fast PC that must rely on this routine to slow it down. Again see rp.c for a fix to tiny_delay(). If all else fails try running the PC at a slower clock speed if you can (some PCs have a Turbo button for this). Q5. PP.EXE complains that the hardware is not attached when I know it is. I have specified the correct port but whatever I do it refuses to work. What am I doing wrong? A5. If the hardware is built correctly then nothing. It's likely you have a pretty fast PC and/or "slow" hardware. To check that the hardware is connected, the program writes to it and reads back the response immediately; it is possible that the hardware doesn't respond in time. See the changes to test_hw() in the source of the PIC reader rp.c to see how you can cure this. Q6. I hate MS-DOS. Will your programmer run under Linux? I hate MS-DOS boxes. Will your programmer run on an Amiga/Macintosh/Atari? A6. The "prog84" package from Wim Lewis will let you use my hardware under Linux; look for it on ftp://ftp.funet.fi/pub/microprocs/pic (in the directory burners). You should also get Ian King's software tools from the same place (in the directory pictools). These programs are probably fairly portable across all PC versions of Unix. For other systems, the easiest thing might be for you to write your own controller in your own favourite language. My C program will need a little work for non-MS-DOS machines, but provided you have a C compiler, a computer with a parallel port, access to I/O routines for the parallel port and finally a millisecond accuracy delay routine it shouldn't be too difficult to get it going. Ironically, having ported the software from MS-DOS, you might find yourself using an MS-DOS emulator in order to run a decent assembler/simulator. I'm told that using the unmodified C program with an MS-DOS emulator works on the Amiga. Q7. I notice your program calls a routine named "erase" before it attempts to program the PIC. The routine uses the undocumented commands 1 and 7. What's going on? A7. This is a routine to disable code protection so that a previously protected chip can be reprogrammed. It has the side-effect of bulk erasing the chip, that is erasing all program and data memory. Microchip recommend that this procedure is performed before any other programming is attempted. However, for some unexplained reason they don't document the procedure for serial mode. I just tried the parallel mode approach and it seems to work. Someone suggested that this routine should only be selected if you are programming a protected PIC thereby decreasing wear and tear on the fuse EEPROM cells. They may have a point. See A11 for other mods of this kind. Q8. How do I produce a suitable file to initialise data EEPROM? A8. The programmer software takes a word (16-bits) of data from the hex file and puts the least significant byte into the EEPROM data memory. A suitable hex file can be created with any assembler. I use MPASM and here's a short example that generates a valid INHX8M data file: list p=16c84 ; org 0 ; data 1,2,3,0xFF data 'S,'t,'r,'i,'n,'g,'. end Note the special handling of the text string because the software ignores every second byte of data. Q9. Your programmer seems to work OK with files produced by MPASM or MPALC. However I prefer to use the mnemonics offered by the Parallax assemblers. Unfortunately your programmer software chokes on Parallax hex files even though they are INHX8M compatible. Can you fix that? A9. The problem (or perhaps advantage) with Parallax files is that they embed FUSE, ID and EEPROM data into the same file and my software doesn't expect that. The best solution is to change the loadhex function to understand these files. Alternatively you can simply ignore the non-program elements of the file by replacing this chunk of loadhex: for ( i=0; i<nwords; ++i, ++address ) { if ( address >= bufsize ) quit("Impossible address"); w = hexword(fp); buf[address] = (hextype == INHX8M)? swab(w): w; } with for ( i=0; i<nwords; ++i, ++address ) { w = hexword(fp); if ( address >= bufsize ) continue; buf[address] = (hextype == INHX8M)? swab(w): w; } Of course there is a similar workaround for the QBasic source; look for the subroutine "LoadHex". It contains a FOR-NEXT loop that in the original looks like: FOR i = 1 TO NWords IF Address >= BufSize THEN Quit ERRHEX, 0, 0, 0 wHi = HexByte%(Chan) wLo = HexByte%(Chan) IF HexType = INHX8M THEN w = 256 * wLo + wHi ELSE w = 256 * wHi + wLo IF Which = ProgMem THEN ProgBuf(Address) = w ELSE DataBuf(Address) = w Address = Address + 1 NEXT i Delete line 2 and bracket the "IF Which = ....." with another IF statement to get this: FOR i = 1 TO NWords wHi = HexByte%(Chan) wLo = HexByte%(Chan) IF HexType = INHX8M THEN w = 256 * wLo + wHi ELSE w = 256 * wHi + wLo IF Address < BufSize THEN IF Which = ProgMem THEN ProgBuf(Address) = w ELSE DataBuf(Address) = w ENDIF Address = Address + 1 NEXT i Q10. I have version 0.3 of your software. Do you have you an updated version? A10. No. The existing version works for me and does everything I need, so I doubt if I'll ever get round to producing a significantly better version. An important function that you might want is a routine to read the PIC and so I have written a separate utility to do that; it is also easy enough to verify a PIC by combining the PIC reader functionality with the loadhex routine from the programmer source. The core parts of rp.c and rp.bas are tiny routines to actually read the PIC and some routines to spit out INHX8M files; the rest is much the same as pp.c and pp.bas. If you _really_ wanted INHX16, check loadhex() for hints on the difference. Q11. The time to program the PIC seems independent of the number of locations that must be programmed. Why? A11. My software programs all locations every time. It is easy to change this behaviour. One modification you might consider would be to read the entire PIC (program/data/fuses) into a buffer and then only reprogram the items that differ from the new values. The verify() and config() routines can be modified and combined to read the entire PIC. Q12. I use the QBasic program and sometimes when I quit I get a blank screen and the machine seems dead. Can I fix that? A12. Yes. If you type CLS the screen will come back to life. Fix the source by adding a CLS statement just before each occurrence of the END statement (a couple of places). You can also replace END with SYSTEM for a more abrupt end. Q13. I use MPASM which amongst other things produces .obj files. The instructions for pp.c say it expects "objfiles" but when I try to use the .obj files it complains. Why? A13. You should use the .hex files produced by MPASM. I know my name is confusing, but it's because when I wrote the program I used the MPALC naming convention. MPASM produces INHX8M by default whereas MPALC produced INHX16, so you might like to change the programmer defaults if you use MPASM (or the Parallax assembler with the A9 fix). Q14. My PC makes a noise when I run your QBasic program. Is anything wrong? A14. No. I use the Qbasic PLAY command to get a small delay and on some PCs this can lead to a slight purr from the internal speaker. If you find it objectionable just replace the "PrgDly" routine with a FOR-NEXT loop that wastes an amount of time of at least 10ms. Q15. Can I use your software from a DOS window under Windows? A15. Try it. On my own PC the C version runs OK, but the QBasic program seems to have problems; perhaps the way I time the programming signals is being interfered with by Windows somehow. Q16. Is that all? A16. I hope so.